Jaderné noviny 258

20. 4. 2004 | Robert Krátký | Jaderné noviny | 4559×

Marc-Christian Petersen je novým správcem řady 2.2. Nový souborový systém PRAMFS. Stav softwarového uspání. Stav fsync(). Co bude s OSS.

Do konference přišlo celkem 1917 emailů, nejvíce jich poslali Andrea Arcangeli, Andrew Morton a Greg KH.

Marc-Christian Petersen je novým správcem řady 2.2, 2 e-maily

24. úno - 26. úno

Marc-Christian Petersen převzal od Alana Coxe správcovství řady 2.2 a vydal verzi 2.2.26:

Jsem velmi rád, že mohu oznámit toto vydání, protože obsahuje několik oprav bezpečnostních chyb, včetně toho posledního problému s mremap().

Doporučuji všem uživatelům 2.2 jader, aby upgradovali.

Pošlete mi, prosím, opravy/patche/atd., na které jsem zapomněl, aby mohly být začleněny do 2.2.27-pre/rc.

Nový souborový systém PRAMFS, 17 e-mailů

3. bře - 18. bře

Steve Longerbeam napsal:

MontaVista Software vyvinula nový filesystém zaměřený na embedded systémy. Rádi bychom jej prosadili do jádra 2.6 nebo 2.7. Nazývá se Protected and Persistent RAM Special Filesystem (PRAMFS). Původně byl vyvinut pro tři velké firmy vyrábějící spotřebitelskou elektroniku, aby jej mohly používat v chytrých mobilech a jiných spotřebitelských zařízeních.

Úvod do PRAMFS a také technické specifikace naleznete na SourceForge stránkách projektu http://pramfs.sourceforge.net/. Je tam také patch pro 2.6.3.

PRAMFS může být na desktopu testován pomocí rezervování určité části fyzické paměti příkazem "mem=". Například stroj s 512M by mohl rezervovat vrchních 32M příkazem "mem=480M". PRAMFS by se pak připojoval takto:

mount -t pramfs -o physaddr=0x1e000000,init=0x2000000 none /mnt/pramfs

Připojil několik úvodních dokumentů, ale Dave Jones poukázal na to, že největším problémem, který brání začlenění této práce, je nejspíše poznámka o patentech na část kódu. Steve odpověděl: MV sice čeká na schválení patentu, ale ten se bude týkat pouze případného budoucího využití technologie v _ne GPL_ operačním systému. Použití v Linuxu nebo jakémkoliv jiném GPL softwaru je bez jakýchkoliv patentových licencí nebo poplatků. Mike Fedyk řekl, že by se to mělo přeložit do právnických termínů a ponechat jako součást samotného patche. Tim Bird připomněl, že přesně takové upozornění už je na začátku každého souboru patche.

Stav softwarového uspání, 17 e-mailů

12. bře - 18. bře

Pavel Machek napsal:

Skutečně se mi nelíbí dvě implementace stejného kódu v jádře. Jsou dva způsoby, jak to řešit:

• odstranit z jádra pmdisk

  • snadné

• odstranit z jádra swsusp, přejmenovat pmdisk na swsusp, opravit všechny chyby, které byly opraveny v swsusp ale ne v pmdisk

  • zdá se, že lidi mají radši kód pmdisk
  • bude potřebovat otestovat v řadě -mm

Co byste volili? Mohu udělat obojí...

Theodore Ts'o odpověděl:

2.6 je údajně stabilní jadernou řadou, takže je-li swsusp v tuto chvíli stabilnější, navrhoval bych swsusp ponechat a odstranit z kernelu pmdisk. Chce-li někdo spravovat samostatný BK-strom obsahující pmdisk přejmenovaný na swsusp a opravit všechny chyby, fajn. Na druhou stranu tu je skupina lidí, kteří dělají něco hodně podobného se swsusp2, a vypadá to, že se jich na testování a práci podílí hodně.

Takže pokud bychom mohli nějak snížit počet *tří* nezávislých implementací na méně než tři, a zvýšit úsilí věnované testování a vývoji zbývajícího kódu, byl by to pokrok.

Mimochodem, Pavle, co ty si myslíš o tom swsusp2 patchi? Mně nejvíce vadí, že vzhledem k tomu, že je to spravované vně jádra, tak je to pořád o nějakých 0,75 revize pozadu oproti aktuálnímu 2.6 kernelu. Množství vlastností - kdyby se někdy podařilo zbavit je všech chyb - je však impozantní.

Pavel odpověděl: Na swsusp2 mi nejvíce vadí, jak je velké. Navíc, když jsem se naposledy díval, byly tam dost nepěkné hooky rozeseté po celém jádře. A pak to má funkce, které se mi nelíbí (grafické obrazovky s ukazatelem průběhu, escape ruší akci) a proměnnésnázvyjakojetento. Na druhou stranu to podporuje highmem a SMP.

Jan Rychter reagoval:

Také má tu výhodu, že naprosto spolehlivě funguje na 2.4. Nepodařilo se mi to shodit už několik měsíců, a to provádím několik uspání/probuzení denně.

Navíc jsou doby uspání/probuzení velmi krátké díky bezvadné komprimaci. Dokonce se mohou měřit se suspend-to-ram.

Myslím, že by bylo lepší nemíchat osobní preference (třeba tu věc s escape) s technickou diskuzí. Z praktického hlediska je swsusp2 jedinou implementací, která funguje spolehlivě a dobře a má komunikativního správce, který je ochoten opravovat objevující se se problémy.

Benjamin Herrenschmidt napsal, že také podporuje začlenění swsusp2 do hlavního kernelu:

Možná s tím nějaké problémy jsou, ale když to ponecháme mimo strom, je víceméně zaručeno, že se na ně nikdo z nás nepodívá a neopraví je ;).

Dostane-li se to do hlavního stromu, rád dokončím tu podporu pro PMac, kterou jsem rychle hacknul pro pmdisk, a pomohu s vyřešením i dalších problémů. Ale nechce se mi to dělat pro nezačleněný projekt.

Pavel se Benjamina zeptal, jestli si myslí, že by to začlenění mělo proběhnout během 2.6 nebo až v rámci 2.7. Benjamin odpověděl: 2.6. Pokud to není moc invazivní, tak nevidím důvod, proč to nezačlenit teď (na kód jsem se ale nedíval). Nezasahuje-li to jinam, pak je to skoro jako přidání ovladače. Pavel kód prohlédl a zjistil, že je velmi invazivní. Měl pocit, že dostat to do 2.6 by bylo hodně těžké a ani 2.7 se mu nezdálo příliš reálné. Další lidi začali diskutovat o tom, co by bylo potřeba změnit, aby byl kód lépe stravitelný.

Stav fsync(), 40 e-mailů

17. bře - 22. bře

Peter Zaitsev se zeptal:

Existuje v Linuxu nějaký způsob, jak provést řádný fsync(), který zajistí, že budou data zapsána na disk?

V současné době na IDE zařízeních fsync() pouze spláchne data do keše disku, což pro ACID záruky, které musí poskytnout databázový server, nestačí.

Řešením je prostě zakázat keš disku, ale to příliš snižuje výkonnost.

Stačil by mi globální přepínač pro jádro, který by povolil spláchnutí keše disku při fsync :).

Jens Axboe řekl: Chris a já máme funkční fsync(). Pročistím to a pošlu patch pro vanilla 2.6.5-rc. Což bylo přesně to, co Peter a další chtěli slyšet.

Co bude s OSS, 21 e-mailů

22. bře - 24. bře

Jos Hulzink napsal: Opravoval jsem několik problémů s "deprecated" v OSS ovladačích a říkal jsem si, jestli to má vůbec smysl, když je celé OSS označeno jako "deprecated" (zastaralé). Přežije OSS až do 2.7 nebo bude brzy odstraněno? (Jinými slovy, mám se o OSS ovladače starat nebo se neobtěžovat?).

Adrian Bunk odpověděl:

OSS zůstane ve 2.6 (2.6 je stabilní řada), ale s největší pravděpodobností bude odstraněno z 2.7.

Já bych s opravami starých hlášek v OSS kódu neztrácel čas. Byl by to čas zbytečně promarněný na kódu, který asi půjde ve 2.7 pryč.

Diego Calleja Garcia řekl: Jako uživatel bych rád měl OSS ovladače, které nemají ALSA ekvivalent, pro svůj starý hardware. Existuje dost karet, pro které jsou jak ALSA, tak OSS ovladače a ALSA funguje v 99 % případů o moc lépe. Ty mohou být klidně odstraněny (i během 2.6), ale chtěl bych ponechat ty, ke kterým ALSA ekvivalent není (zvláště když teď máme strom -tiny ;), i když chápu, že nemají-li správce, budou odstraněny...

---

V originálu Kernel Traffic 258 vyšla navíc ještě tato témata:

• Linux 2.6.4-mm2 Released
• bkbits.net Improvements
• Trying To Clarify Software Suspend
• Linux 2.6.5-rc1-mm2 Released
• libata Update Against 2.6
• Linux 2.6.5-rc2 Released
• Linux 2.4.26-pre5 Released
• Linux 2.6.5-rc2-mm1 Released
• Setting A Non-Executable Stack For ELF Binaries
• Linux 2.2.27-pre1 Released

Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.

       

Komentáře